Issues in Kernel Design

type structures The concept of using extended types (such as illustrated by Simula classes,18 CLU clusters,19 Alphard forms,7 or Euclid modules) to organize software is quite valuable. However, Janson15 points out that most efforts to employ strict type extension methods in programming are done with the underlying assumption of unlimited quantities of resources available. In the internal structure of an operating system or its kernel, this assumption is invalid, of course. One of the most obvious cases where finite resource limits interact with system structure occurs in virtual memory systems, potentially reSUlting in a structural circularity. Main memory is finite, so system software is constructed to give the illusion of a larger address space by sensing page faults and performing necessary I/Os in a manner invisible to the process involved. However, one may well wish to run this virtual memory software as a process like other processes. Further, the process management software can benefit from being written with the assumption that a large, From the collection of the Computer History Museum (www.computerhistory.org) virtual address space is available. With the obvious circular dependency in mind, it is not clear whether process types or virtual memory types should be the lower level, with the other built on top. Reed outlines a method of defining multiple levels of types to break the cycle. Lower levels implement a small fixed number or amount of the resource, using small amounts of resources in so doing. Higher levels reimplement the resource in large numbers or amounts, by multiplexing the lower level ones. In medium sized systems such as UCLA Unix, such a mUitiple tiered structure is not necessary.